Návrhový vzor Observer s WeakRef v JavaScriptu: Tvorba paměťově efektivních systémů událostí

Ve světě moderního webového vývoje se Single Page Applications (SPA) staly standardem pro vytváření dynamických a responzivních uživatelských zážitků. Tyto aplikace často běží po dlouhou dobu, spravují složité stavy a zpracovávají nespočet interakcí uživatele. Tato dlouhověkost však s sebou nese skrytou cenu: zvýšené riziko úniků paměti. Únik paměti, kdy aplikace drží paměť, kterou již nepotřebuje, může časem zhoršit výkon, což vede ke zpomalení, pádům prohlížeče a špatnému uživatelskému zážitku. Jeden z nejčastějších zdrojů těchto úniků spočívá v základním návrhovém vzoru: vzoru Observer.

Návrhový vzor Observer je základním kamenem architektury řízené událostmi, který umožňuje objektům (pozorovatelům) přihlásit se k odběru a přijímat aktualizace od centrálního objektu (subjektu). Je elegantní, jednoduchý a neuvěřitelně užitečný. Jeho klasická implementace má však zásadní nedostatek: subjekt udržuje silné reference na své pozorovatele. Pokud pozorovatel již není potřebný pro zbytek aplikace, ale vývojář ho zapomene explicitně odhlásit od subjektu, nikdy nebude uvolněn garbage collectorem. Zůstane uvězněn v paměti jako duch strašící výkon vaší aplikace.

A právě zde přichází na pomoc moderní JavaScript se svými funkcemi z ECMAScript 2021 (ES12) a poskytuje mocné řešení. Využitím WeakRef a FinalizationRegistry můžeme vytvořit paměťově efektivní vzor Observer, který se automaticky sám uklízí a předchází tak těmto běžným únikům. Tento článek je hloubkovým ponorem do této pokročilé techniky. Prozkoumáme problém, porozumíme nástrojům, vytvoříme robustní implementaci od nuly a probereme, kdy a kde by se tento mocný vzor měl ve vašich globálních aplikacích používat.

Pochopení jádra problému: Klasický vzor Observer a jeho paměťová stopa

Než dokážeme ocenit řešení, musíme plně pochopit problém. Návrhový vzor Observer, známý také jako Publisher-Subscriber, je navržen k oddělení komponent. Subjekt (nebo Publisher) udržuje seznam svých závislých, nazývaných Pozorovatelé (nebo Subscribers). Když se stav Subjektu změní, automaticky upozorní všechny své Pozorovatele, obvykle voláním specifické metody na nich, jako je například update().

Podívejme se na jednoduchou, klasickou implementaci v JavaScriptu.

Jednoduchá implementace subjektu

Zde je základní třída Subject. Má metody pro přihlášení, odhlášení a upozornění pozorovatelů.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} has subscribed.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} has unsubscribed.`);

  }

 

  notify(data) {

    console.log('Notifying observers...');

    this.observers.forEach(observer => observer.update(data));

  }

}

A zde je jednoduchá třída Observer, která se může přihlásit k odběru u Subjektu.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

Skryté nebezpečí: Zůstávající reference

Tato implementace funguje naprosto v pořádku, pokud pečlivě spravujeme životní cyklus našich pozorovatelů. Problém nastává, když to neděláme. Zvažme běžný scénář ve velké aplikaci: dlouho žijící globální úložiště dat (Subjekt) a dočasná UI komponenta (Pozorovatel), která zobrazuje některá z těchto dat.

Nasimulujme si tento scénář:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // Komponenta plní svou funkci...

 

  // Nyní uživatel přejde jinam a komponenta již není potřeba.

  // Vývojář může zapomenout přidat úklidový kód:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // Uvolníme naši referenci na komponentu.

}

 

manageUIComponent();

 

// Později v životním cyklu aplikace...

dataStore.notify('New data available!');

Ve funkci `manageUIComponent` vytvoříme `chartComponent` a přihlásíme jej k našemu `dataStore`. Později nastavíme `chartComponent` na `null`, čímž signalizujeme, že jsme s ním skončili. Očekáváme, že JavaScript garbage collector (GC) uvidí, že na tento objekt již neexistují žádné reference, a uvolní jeho paměť.

Ale existuje další reference! Pole `dataStore.observers` stále drží přímou, silnou referenci na objekt `chartComponent`. Kvůli této jediné zůstávající referenci nemůže garbage collector paměť uvolnit. Objekt `chartComponent` a veškeré prostředky, které drží, zůstanou v paměti po celou dobu životnosti `dataStore`. Pokud se to stane opakovaně – například pokaždé, když uživatel otevře a zavře modální okno – využití paměti aplikace bude neomezeně růst. Toto je klasický únik paměti.

Nová naděje: Představení WeakRef a FinalizationRegistry

ECMAScript 2021 představil dvě nové funkce speciálně navržené pro řešení těchto druhů problémů se správou paměti: `WeakRef` a `FinalizationRegistry`. Jsou to pokročilé nástroje a měly by být používány s opatrností, ale pro náš problém se vzorem Observer jsou dokonalým řešením.

Co je WeakRef?

Objekt `WeakRef` drží slabou referenci na jiný objekt, nazývaný jeho cíl. Klíčový rozdíl mezi slabou referencí a normální (silnou) referencí je tento: slabá reference nebrání tomu, aby byl její cílový objekt uvolněn garbage collectorem.

Pokud jediné reference na objekt jsou slabé, JavaScriptový engine může objekt zničit a uvolnit jeho paměť. To je přesně to, co potřebujeme k vyřešení našeho problému s Observerem.

Chcete-li použít `WeakRef`, vytvoříte jeho instanci a předáte cílový objekt do konstruktoru. Pro pozdější přístup k cílovému objektu použijete metodu `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// Pro přístup k objektu:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Object is still alive: ${retrievedObject.id}`); // Výstup: Object is still alive: 42

} else {

  console.log('Object has been garbage collected.');

}

Klíčové je, že `deref()` může vrátit `undefined`. To se stane, pokud byl `targetObject` uvolněn garbage collectorem, protože na něj již neexistují žádné silné reference. Toto chování je základem našeho paměťově efektivního vzoru Observer.

Co je FinalizationRegistry?

Zatímco `WeakRef` umožňuje, aby byl objekt uvolněn z paměti, nedává nám čistý způsob, jak zjistit, kdy byl uvolněn. Mohli bychom periodicky kontrolovat `deref()` a odstraňovat `undefined` výsledky z našeho seznamu pozorovatelů, ale to je neefektivní. Zde přichází na řadu `FinalizationRegistry`.

A `FinalizationRegistry` vám umožňuje zaregistrovat callback funkci, která bude vyvolána poté, co byl zaregistrovaný objekt uvolněn garbage collectorem. Je to mechanismus pro úklid po "smrti" objektu.

Funguje to takto:

1. Vytvoříte registr s úklidovým callbackem.
2. Zaregistrujete (`register()`) objekt u registru. Můžete také poskytnout `heldValue`, což je kus dat, který bude předán vašemu callbacku, když je objekt uvolněn. Tato `heldValue` nesmí být přímou referencí na samotný objekt, protože by to zmařilo celý účel!

// 1. Vytvoření registru s úklidovým callbackem

const registry = new FinalizationRegistry(heldValue => {

  console.log(`An object has been garbage collected. Cleanup token: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Temporary Data' };

  let cleanupToken = 'temp-data-123';

 

  // 2. Registrace objektu a poskytnutí tokenu pro úklid

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack zde vychází z rozsahu platnosti

})();

 

// Někdy v budoucnu, po spuštění GC, se v konzoli zobrazí:

// "An object has been garbage collected. Cleanup token: temp-data-123"

Důležitá upozornění a osvědčené postupy

Než se pustíme do implementace, je klíčové porozumět povaze těchto nástrojů. Chování garbage collectoru je vysoce závislé na implementaci a je nedeterministické. To znamená:

• Nemůžete předvídat, kdy bude objekt uvolněn. Může to být sekundy, minuty, nebo dokonce déle poté, co se stane nedosažitelným.
• Nemůžete se spoléhat na to, že callbacky `FinalizationRegistry` se spustí včas nebo předvídatelně. Jsou určeny pro úklid, nikoli pro kritickou aplikační logiku.
• Nadměrné používání `WeakRef` a `FinalizationRegistry` může ztížit uvažování o kódu. Vždy upřednostňujte jednodušší řešení (jako explicitní volání `unsubscribe`), pokud jsou životní cykly objektů jasné a spravovatelné.

Tyto funkce se nejlépe hodí pro situace, kdy je životní cyklus jednoho objektu (pozorovatele) skutečně nezávislý a neznámý pro jiný objekt (subjekt).

Tvorba vzoru `WeakRefObserver`: Implementace krok za krokem

Nyní zkombinujme `WeakRef` a `FinalizationRegistry` k vytvoření paměťově bezpečné třídy `WeakRefSubject`.

Krok 1: Struktura třídy `WeakRefSubject`

Naše nová třída bude ukládat `WeakRef` na pozorovatele místo přímých referencí. Bude také mít `FinalizationRegistry` pro automatický úklid seznamu pozorovatelů.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Použití Set pro snadnější odstraňování

 

    // Finalizační callback. Přijímá hodnotu, kterou poskytneme při registraci.

    // V našem případě bude touto hodnotou samotná instance WeakRef.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: An observer has been garbage collected. Cleaning up...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Pro náš seznam pozorovatelů používáme `Set` místo `Array`. Je to proto, že odstranění položky ze `Set` je mnohem efektivnější (průměrná časová složitost O(1)) než filtrování `Array` (O(n)), což bude užitečné v naší úklidové logice.

Krok 2: Metoda `subscribe`

Metoda `subscribe` je místo, kde začíná kouzlo. Když se pozorovatel přihlásí, uděláme následující:

1. Vytvoříme `WeakRef`, který ukazuje na pozorovatele.
2. Přidáme tento `WeakRef` do naší sady `observers`.
3. Zaregistrujeme původní objekt pozorovatele u našeho `FinalizationRegistry` a jako `heldValue` použijeme nově vytvořený `WeakRef`.

// Uvnitř třídy WeakRefSubject...

subscribe(observer) {

  // Zkontrolujte, zda pozorovatel s touto referencí již neexistuje

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Observer already subscribed.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Zaregistrujte původní objekt pozorovatele. Když bude uvolněn,

  // finalizer bude zavolán s `weakRefObserver` jako argumentem.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('An observer has subscribed.');

}

Toto nastavení vytváří chytrou smyčku: subjekt drží slabou referenci na pozorovatele. Registr drží silnou referenci na pozorovatele (interně), dokud není uvolněn garbage collectorem. Jakmile je uvolněn, je spuštěn callback registru s instancí slabé reference, kterou pak můžeme použít k úklidu naší sady `observers`.

Krok 3: Metoda `unsubscribe`

I s automatickým úklidem bychom stále měli poskytovat manuální metodu `unsubscribe` pro případy, kdy je potřeba deterministické odstranění. Tato metoda bude muset najít správný `WeakRef` v naší sadě dereferencováním každého z nich a porovnáním s pozorovatelem, kterého chceme odstranit.

// Uvnitř třídy WeakRefSubject...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // DŮLEŽITÉ: Musíme také odregistrovat z finalizeru

    // abychom zabránili zbytečnému spuštění callbacku později.

    this.cleanupRegistry.unregister(observer);

    console.log('An observer has unsubscribed manually.');

  }

}

Krok 4: Metoda `notify`

Metoda `notify` prochází naši sadu `WeakRef`. Pro každý z nich se pokusí `deref()` získat skutečný objekt pozorovatele. Pokud `deref()` uspěje, znamená to, že pozorovatel je stále naživu, a můžeme zavolat jeho metodu `update`. Pokud vrátí `undefined`, pozorovatel byl uvolněn a můžeme ho jednoduše ignorovat. `FinalizationRegistry` nakonec odstraní jeho `WeakRef` ze sady.

// Uvnitř třídy WeakRefSubject...

notify(data) {

  console.log('Notifying observers...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // Pozorovatel je stále naživu

      observer.update(data);

    } else {

      // Pozorovatel byl uvolněn.

      // FinalizationRegistry se postará o odstranění tohoto weakRef ze sady.

      console.log('Found a dead observer reference during notification.');

    }

  }

}

Vše dohromady: Praktický příklad

Vraťme se k našemu scénáři s UI komponentou, ale tentokrát použijeme naši novou `WeakRefSubject`. Pro jednoduchost použijeme stejnou třídu `Observer` jako předtím.

// Stejná jednoduchá třída Observer

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

Nyní vytvořme globální datovou službu a nasimulujme dočasný UI widget.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Creating and subscribing new widget ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // Widget je nyní aktivní a bude přijímat notifikace

  globalDataService.notify({ price: 100 });

 

  console.log('--- Destroying widget (releasing our reference) ---');

  // S widgetem jsme skončili. Nastavíme naši referenci na null.

  // NEMUSÍME volat unsubscribe().

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- After widget destruction, before garbage collection ---');

globalDataService.notify({ price: 105 });

Po spuštění `createAndDestroyWidget()` je na objekt `chartWidget` odkazováno pouze pomocí `WeakRef` uvnitř našeho `globalDataService`. Protože se jedná o slabou referenci, objekt je nyní způsobilý pro uvolnění garbage collectorem.

Když se garbage collector nakonec spustí (což nemůžeme předvídat), stanou se dvě věci:

1. Objekt `chartWidget` bude odstraněn z paměti.
2. Bude spuštěn callback našeho `FinalizationRegistry`, který následně odstraní nyní mrtvý `WeakRef` ze sady `globalDataService.observers`.

Pokud zavoláme `notify` znovu poté, co garbage collector proběhl, volání `deref()` vrátí `undefined`, mrtvý pozorovatel bude přeskočen a aplikace bude nadále fungovat efektivně bez úniků paměti. Úspěšně jsme oddělili životní cyklus pozorovatele od subjektu.

Kdy použít (a kdy se vyhnout) vzoru `WeakRefObserver`

Tento vzor je mocný, ale není to všelék. Zavádí složitost a spoléhá na nedeterministické chování. Je klíčové vědět, kdy je to ten správný nástroj pro danou práci.

Ideální případy použití

• Dlouho žijící subjekty a krátce žijící pozorovatelé: Toto je kanonický případ použití. Globální služba, datové úložiště nebo cache (subjekt), která existuje po celou dobu životnosti aplikace, zatímco četné UI komponenty, dočasní workeři nebo pluginy (pozorovatelé) jsou často vytvářeni a ničeni.
• Mechanismy cachování: Představte si cache, která mapuje složitý objekt na nějaký vypočítaný výsledek. Můžete použít `WeakRef` pro klíčový objekt. Pokud je původní objekt uvolněn garbage collectorem ze zbytku aplikace, `FinalizationRegistry` může automaticky vyčistit odpovídající záznam ve vaší cache, čímž zabrání nadměrnému využití paměti.
• Architektury pluginů a rozšíření: Pokud vytváříte jádrový systém, který umožňuje modulům třetích stran přihlásit se k odběru událostí, použití `WeakRefObserver` přidává vrstvu odolnosti. Zabraňuje tomu, aby špatně napsaný plugin, který zapomene odhlásit odběr, způsobil únik paměti ve vaší jádrové aplikaci.
• Mapování dat na DOM elementy: Ve scénářích bez deklarativního frameworku můžete chtít asociovat nějaká data s DOM elementem. Pokud to uložíte do mapy s DOM elementem jako klíčem, můžete vytvořit únik paměti, pokud je element odstraněn z DOM, ale stále je ve vaší mapě. `WeakMap` je zde lepší volbou, ale princip je stejný: životní cyklus dat by měl být vázán na životní cyklus elementu, ne naopak.

Kdy se držet klasického Observeru

• Těsně spojené životní cykly: Pokud jsou subjekt a jeho pozorovatelé vždy vytvářeni a ničeni společně nebo ve stejném rozsahu platnosti, režie a složitost `WeakRef` jsou zbytečné. Jednoduché, explicitní volání `unsubscribe()` je čitelnější a předvídatelnější.
• Výkonnostně kritické části kódu: Metoda `deref()` má malou, ale nenulovou výkonnostní náročnost. Pokud notifikujete tisíce pozorovatelů stokrát za sekundu (např. v herní smyčce nebo vysokofrekvenční vizualizaci dat), klasická implementace s přímými referencemi bude rychlejší.
• Jednoduché aplikace a skripty: Pro menší aplikace nebo skripty, kde je životnost aplikace krátká a správa paměti není významným problémem, je klasický vzor jednodušší na implementaci a pochopení. Nepřidávejte složitost tam, kde není potřeba.
• Když je vyžadován deterministický úklid: Pokud potřebujete provést akci přesně v okamžiku, kdy je pozorovatel odpojen (např. aktualizace čítače, uvolnění specifického hardwarového prostředku), musíte použít manuální metodu `unsubscribe()`. Nedeterministická povaha `FinalizationRegistry` jej činí nevhodným pro logiku, která se musí provádět předvídatelně.

Širší důsledky pro softwarovou architekturu

Zavedení slabých referencí do vysokoúrovňového jazyka, jako je JavaScript, signalizuje zrání platformy. Umožňuje vývojářům budovat sofistikovanější a odolnější systémy, zejména pro dlouho běžící aplikace. Tento vzor podporuje posun v architektonickém myšlení:

• Skutečné oddělení: Umožňuje úroveň oddělení, která přesahuje pouhé rozhraní. Nyní můžeme oddělit samotné životní cykly komponent. Subjekt již nepotřebuje vědět nic o tom, kdy jsou jeho pozorovatelé vytvářeni nebo ničeni.
• Odolnost jako součást návrhu: Pomáhá budovat systémy, které jsou odolnější vůči chybám programátora. Zapomenuté volání `unsubscribe()` je běžná chyba, kterou může být obtížné odhalit. Tento vzor zmírňuje celou třídu těchto chyb.
• Umožnění autorům frameworků a knihoven: Pro ty, kteří vytvářejí frameworky, knihovny nebo platformy pro ostatní vývojáře, jsou tyto nástroje neocenitelné. Umožňují vytváření robustních API, která jsou méně náchylná k nesprávnému použití ze strany spotřebitelů knihovny, což vede k celkově stabilnějším aplikacím.

Závěr: Mocný nástroj pro moderního JavaScript vývojáře

Klasický vzor Observer je základním stavebním kamenem softwarového designu, ale jeho spoléhání na silné reference je již dlouho zdrojem subtilních a frustrujících úniků paměti v JavaScriptových aplikacích. S příchodem `WeakRef` a `FinalizationRegistry` v ES2021 máme nyní nástroje k překonání tohoto omezení.

Prošli jsme cestu od pochopení základního problému zůstávajících referencí až po vybudování kompletního, paměťově efektivního `WeakRefSubject` od základů. Viděli jsme, jak `WeakRef` umožňuje, aby byly objekty uvolněny garbage collectorem, i když jsou 'pozorovány', a jak `FinalizationRegistry` poskytuje automatizovaný mechanismus úklidu, který udržuje náš seznam pozorovatelů čistý.

S velkou mocí však přichází velká zodpovědnost. Jsou to pokročilé funkce, jejichž nedeterministická povaha vyžaduje pečlivé zvážení. Nejsou náhradou za dobrý návrh aplikace a pečlivou správu životního cyklu. Ale když se aplikují na správné problémy – jako je správa komunikace mezi dlouho žijícími službami a efemérními komponentami – je vzor WeakRef Observer výjimečně mocnou technikou. Jejím zvládnutím můžete psát robustnější, efektivnější a škálovatelnější JavaScriptové aplikace, připravené čelit požadavkům moderního, dynamického webu.